📚 Week 3 · Unit II · Lecture 8
Continuous Integration (CI)
& Continuous Delivery (CD)

The automated engine room of DevOps — how teams merge code constantly and keep it always ready to release.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateMon, 22 Jun 2026 · 11:00 AM – 12:00 PM
ProgrammeBTech CSE – 5th / 6th Semester
Today's Agenda
1
Recap — MVP & Application Deployment
2
What Is Continuous Integration (CI)?
3
The CI Workflow & Key Practices
4
What Is Continuous Delivery (CD)?
5
Continuous Delivery vs Continuous Deployment
6
Building a CI/CD Pipeline — Tools & Example
Recap
Where We Left Off
✅
Lecture 7: We learned that an MVP validates learning with minimal effort, and that Application Deployment moves code from development through staging into production — using strategies like Blue-Green, Canary, and Rolling deployment.
🎯
Today: We open the engine that powers fast, safe deployment — CI/CD. CI/CD is the automated machinery that takes a developer's code commit and turns it into a deployable, trustworthy build, again and again, every day.
The Problem Before CI/CD
  • "Integration Hell" — merging code once every few weeks caused massive conflicts
  • Manual testing was slow, inconsistent, and error-prone
  • Releases were rare, risky, all-hands-on-deck events
The CI/CD Answer
  • Integrate code constantly — multiple times per day
  • Automate every test, every time, on every change
  • Keep the software always in a releasable state
Definition
What Is Continuous Integration (CI)?

Continuous Integration is the practice of merging all developers' code changes into a shared repository frequently — and automatically verifying each merge with a build and a suite of tests.

— Martin Fowler, Software Engineer & Author
🔀
Merge Frequently
Developers push small changes to the main branch multiple times a day, instead of working in long-lived, isolated branches.
🤖
Build Automatically
Every commit triggers an automated build — compiling code and packaging it — with zero manual steps.
🧪
Test Automatically
Automated test suites run on every build, catching bugs within minutes of being introduced — not weeks later.
💡
Key Insight: CI's core promise is simple — find problems early, when they're cheap to fix. A bug caught 5 minutes after a commit costs minutes to fix. The same bug found in production can cost days and damage user trust.
Motivation
Why CI Exists: "Integration Hell"

Before CI became standard practice, teams would work in isolation for weeks, then attempt to merge everyone's changes at once — a painful, unpredictable process developers nicknamed "Integration Hell."

🔥 Without CI
  • Developers work in isolation for days/weeks
  • Merging causes massive, hard-to-resolve conflicts
  • Bugs from team member A break code from team member B — discovered late
  • Integration becomes a dreaded, infrequent event
  • Release dates slip due to last-minute merge chaos
✅ With CI
  • Developers integrate small changes constantly
  • Conflicts are small, frequent, and easy to resolve
  • Automated tests catch breakage within minutes
  • Integration becomes routine and low-risk
  • The codebase is always close to a releasable state
📌
Rule of thumb: The longer code sits unintegrated, the more expensive integration becomes. CI flips the cost curve by making integration small, frequent, and cheap.
Workflow
How a CI Pipeline Works
📝 CommitPush to shared repo
🔔 TriggerCI server detects push
🔨 BuildCompile / install deps
🧪 TestUnit + integration tests
📊 ReportPass/fail feedback
# Example: minimal GitHub Actions CI workflow name: CI Pipeline on: [push, pull_request] jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: "Install dependencies" run: npm install - name: "Run tests" run: npm test
⚡
What happens on failure? If the build or any test fails, the CI server immediately notifies the developer (Slack, email, or a red ✗ on the commit). The broken change is fixed or reverted before it can affect anyone else — this is the core discipline of CI.
Key Practices
CI Best Practices
🌳
Maintain a Single Source Repository
Everyone commits to one shared version-controlled repository (e.g. Git) — no untracked code on someone's laptop.
🤖
Automate the Build
One command should build the entire system — no manual configuration steps that vary by machine.
🧪
Make the Build Self-Testing
The build includes automated tests, and the build is only "successful" if those tests pass too.
⏱️
Commit Frequently
Push small changes daily (or multiple times a day) rather than large, infrequent merges.
🪞
Keep the Build Fast
A CI build that takes hours discourages frequent commits. Aim for feedback within minutes.
🚨
Fix Broken Builds Immediately
A red (failing) build is the team's top priority — no new work continues until it's green again.
Definition
What Is Continuous Delivery (CD)?

Continuous Delivery is the practice of keeping your codebase always in a deployable state — every change that passes automated tests is automatically prepared for a release, ready to go live with the click of a button.

📦
Always Releasable
At any moment, the latest build that passed CI could safely go to production — no scrambling required.
🧰
Extends CI
CD picks up where CI leaves off — taking a tested build and automatically pushing it through staging environments.
🙋
Human Approves Release
A person (e.g. release manager, product owner) still decides when to push the button to deploy to production.
💡
Key Insight: CD removes the technical risk and effort of releasing — the remaining decision of when to release becomes a business choice, not an engineering bottleneck.
Workflow
Extending CI into a CD Pipeline
📝 CommitDeveloper pushes code
🔨 CI Build & TestCompile + automated tests
📦 PackageCreate release artifact
🧭 Deploy to StagingAutomatic
🧪 Acceptance TestsEnd-to-end / UAT
🙋 Manual ApprovalHuman decides "go live"
🚀 Deploy to ProductionOne click
📌
Notice the difference from pure CI: CI stops once tests pass on a build. CD continues that pipeline all the way through staging and acceptance testing, stopping only at a manual approval gate before production.
Critical Distinction
Continuous Delivery vs Continuous Deployment

These two terms are frequently confused — even in industry — but they differ in exactly one important step: who (or what) triggers the production release.

Dimension Continuous Delivery Continuous Deployment
Production Release Manual approval required Fully automatic — no human gate
Speed Release whenever business decides Released the moment it passes all tests
Risk Tolerance Needed Moderate — human reviews before go-live High — requires extremely strong automated test coverage
Typical Use Case Regulated industries, enterprise software, banking SaaS products, web apps, mature DevOps teams (e.g. Netflix, Etsy)
Pipeline Stops At "Ready for Production" gate Production itself
⚠️
Exam tip: Both Continuous Delivery and Continuous Deployment require Continuous Integration as their foundation. You cannot have reliable CD without solid CI underneath it. Remember: CI → Continuous Delivery → Continuous Deployment is a maturity progression, not three unrelated practices.
Maturity Model
The CI/CD Maturity Ladder

Most organizations climb this ladder gradually — few teams start at full Continuous Deployment on day one.

0
No Automation: Manual builds, manual testing, manual deployment. High risk, slow, error-prone.
1
Continuous Integration: Code is merged and tested automatically on every commit. Builds are verified, but deployment is still manual.
2
Continuous Delivery: Every tested build is automatically packaged and staged, ready to deploy with one click — but a human approves the final release.
3
Continuous Deployment: Every change that passes all automated checks goes live automatically — no human gate at all.
🎯 Bottom Line

Each rung builds on the one below it. Skipping CI and jumping straight to automated production deployment is a recipe for disaster — strong CI discipline is the non-negotiable foundation for everything above it.

Why It Matters
Benefits of CI/CD
↓90%
Reduction in integration-related bugs (typical)
Mins
Feedback time on a broken build vs. days/weeks before
↑↑
Deployment frequency — daily or hourly vs monthly
↓Risk
Smaller, more frequent releases reduce blast radius
For Developers
  • Catch bugs minutes after introducing them, not months later
  • Spend less time on painful merge conflicts
  • Confidence to refactor and improve code regularly
For the Business
  • Faster time-to-market for new features
  • Lower cost of fixing defects (caught early)
  • Reliable, predictable, low-stress releases
Tooling
Popular CI/CD Tools
🔧
Jenkins
The original open-source CI/CD automation server. Highly extensible via plugins, self-hosted, widely used in enterprises.
🐙
GitHub Actions
CI/CD built directly into GitHub. Workflows defined in YAML, triggered by repo events like push or pull request.
🦊
GitLab CI/CD
Integrated pipeline tool within GitLab — covers the full DevOps lifecycle from code to monitoring in one platform.
☁️
CircleCI / Travis CI
Cloud-hosted CI/CD platforms, popular for their simplicity and fast setup for open-source and small teams.
🐳
Docker
Packages applications into portable containers — ensuring "it works on my machine" becomes "it works everywhere."
☸️
Kubernetes + ArgoCD
Orchestrates containerized deployments at scale; ArgoCD enables GitOps-style continuous deployment.
Clarifications
Common CI/CD Misconceptions
❌
"CI just means using a CI tool like Jenkins" — False. Installing Jenkins doesn't give you CI. CI is a discipline: frequent commits, automated tests, and a team commitment to fixing broken builds immediately.
❌
"Continuous Delivery and Continuous Deployment are the same thing" — False. Delivery stops at a manual approval gate; Deployment removes that gate entirely and ships automatically.
❌
"CI/CD eliminates the need for testing" — False. CI/CD is only as good as the automated tests behind it. Poor test coverage means CI/CD will confidently ship broken code, fast.
✅
Good Practice: Strong CI/CD = disciplined small commits + comprehensive automated tests + fast feedback + a team culture that treats a broken build as a top priority.
Lecture Summary
Key Takeaways

Lecture 8 — Continuous Integration (CI) & Continuous Delivery (CD)

1
CI = Frequent, Tested MergesDevelopers integrate small changes constantly, with automated builds and tests catching bugs within minutes.
2
Integration Hell, SolvedCI replaces rare, painful, large merges with frequent, small, low-risk ones.
3
CD = Always ReleasableContinuous Delivery extends CI so every passing build is automatically staged and ready to ship.
4
Delivery ≠ DeploymentDelivery keeps a human approval gate before production; Deployment removes it entirely.
5
A Maturity LadderNo Automation → CI → Continuous Delivery → Continuous Deployment — each stage builds on the last.
6
Tools Enable, Discipline DrivesJenkins, GitHub Actions, GitLab CI, Docker, and Kubernetes only work if backed by strong testing culture.
📚 Next Lecture

Lecture 9 (Tue, 23 Jun): CAMS — Culture & Automation; Test-Driven Development — We'll dive deeper into the cultural foundations of DevOps and how Test-Driven Development feeds directly into the CI pipelines we explored today.

Dr. Mohsin Furkh Dar · School of Computer Sciences · UPES Dehradun

CSDV3016P / CSDV3017 · DevOps Overview · Summer 2026